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ABSTRACT: 

A method and system Is disclosed for detaching Java applets from the constraints of the 
application such as a browser which provides the Java engine for executing those applets. Thus, 
the applets, when detached, can appear in a detached window which is more easily controllable 
by the operating environment desktop. The Java applets continue to run under the application's 
virtual machine but do so without regard to the graphical interface limits of the application. 
Further, if the application that launched the applet proceeds to a new URL location, the Java 
applet continues to run. Also, the applet once detached, can be reattached into the application 
to appear in the application history. 



(19) 



J 



Europaischea Patentamt 
European Patent Office 
Office europeen des brevets 



(12) 



(43) Date of pubiication: 

27.01.1999 Bulletin 19991^)4 

(21) Application number: 98305935.3 

(22) Date of filing: 24.07.1998 



(11) EP 0 893 758 A2 

EUROPEAN PATENT APPLICATION 

(51) tntci.fr G06F9/44 



(84) Designated Contracting States: 


(72) Inventors: 


AT BE CH CY OE DK ES R FR GB GR IE IT LI LU 


• Razavi, Behfar 


MC NL PT SE 


San Jose, Calffornla 95123 (US) 


Designated Extension States: 


• Harshbarger, Eric 


ALLT LVMK RO SI 


San Francisco, California 94132 (US) 


(30) Priority: 25.07.1997 US 910481 


(74) Representative: Foster. Mark Charles et al 




Edward Evans & Co., 


(71) Applicant: Sun MIcrosyetefns, Inc. 


Chancery House, 


Palo Alto, Calif omta 94303-4900 (US) 


53-64 Chancery Lane 




London WC2A 1 SD (GB) 


(54) Detachable java applets 



(57) A method and system is disclosed for detaching 
Java applets from the constraints of the application such 
as a browser which provides the Java engine for exe- 
cuting those applets. Thus, the applets, when detached, 
can appear in a detached window which is more eastty 
controllable by the operating environment desktop. The 



Java applets continue to run under the application's vir- 
tual machine but do so without regard to the graphical 
interface limits of the application. Further, if the applica- 
tion that launched the applet proceeds to a new URL 
k^cation, the Java applet continues to run. Also, the ap- 
plet, once detached, can be reattached Into the applica- 
tion to appear in the application history. 



^ ITART "j 



.l£-4nw tppto is 




I on Otoe*- I ^ 



CM 

< 

00 

to 

CO 

o> 

00 

o 

Q. 
liJ 



wiodn 


150 ^ \^ 
^ ■ ■ prapcna of dcncfted 









HGURE2 



PrintadbyJouw. 7S001 PATVStFR) 



EP 0 893 758 A2 

Description 

The present invention relates to the field of computer software. More specifically, the present invention relates to 
applets and their relationship to an operating environment. 

s 

Description of Related Art 

Recent versions of applications such as browsers like Netscape Navigator 3.0™ or Hot Java™ (a product of Sun 
Microsystems, the Sun logo and Hot Java are trademarks or registered trademarks of Sun Microsystems in the United 

10 States and other countries) have provided lor the use of platlorm-independent 'applets' which can be downtoaded as 
pre-compiled Java byte-codes (intermediate level tnstructkxis). These applets are executed via a 'virtual machine,* 
which is a platform-specific environment that interprets or compiles the applet code and performs the high-level in- 
structions therein. One popular and predominant applet programming language, developed by Sun Microsystems, Inc., 
is known as 'Java™' (a product of Sun Microsystems, the Sun logo and Java are trademarks or registered trademarks 

'5 of Sun Mcrosystems in the United States and other countries). Applets programmed in Java or minor variations thereof 
are referred to as Java applets. 

The key usefulness of Java applets is that they are platform-independent, i.e., a Java applet written for platfonn 
A will run without modificatkxi on platform B provided that both platform A and platform B have virtual machines capable 
of executing applet code for their respective platfonms. Even though Java applets are platform-independent, the char- 

20 acteristics, quirks and iimitatkxis of the applications from which they are spawned weaken the flexibility by causing the 
applets to become essentially 'applicatkxi-dependsnt.* For example, one limitatkvi of Java applets when called from 
HTML (Hypertext Markup Language) code for the Sun operating system version of Netscape Navigator is that when 
applets are called, the HTML tag for the call must include a height and wkfth. thus defining a window size that the 
applet must execute within. When running inside the application window, the applet is constrained by the stated height 

25 and width tag and thus, any output, input, diak>g boxes or pop-up windows that are generated for the applet must 
appear within tfiat constraint. 

In this situation, where the applet window is a 'sub-window* of the application window, the applet window suffers 
several impediments. First, the applet window cannot be closed unless the applcation is quit or until the applKation 
transitkxis to receive data from a new host (In the same window that launched (spawned) the applet). And concomitant 

30 with that limitation, when the application that spawned the applet transitkxis to a new URL (Uniform Resource Locator- 
the 'address' of the host visited by the applicatkxi) then the applet window closes and the applet ceases execution. 
The cessation of the applet is out of the control of the user. In certain instances, It is desirable to continue running the 
applet even though the application has transitksned to a different URL. For instance, a user may desire a streaming 
audb applet that plays content from an external or rerrxite source which is launched from URL A to continue playing 

36 even though the applicatnn has proceeded to URL 8, which does not have the same applet. Under current practice, 
it wouU be n«:essary to open or spawn a new instance of the applcatkxi (i.e., open a new application window) to 
receive its content from URL B so that the other appltcatkxi instance continues to play the audb applet. But this ap- 
proach suffers from several maladies. 

First, launching a new application instance may involve an increase in merrxsry and system resource utilization 

40 whch will diminish the performance of both the applet and the new applicatkxt instance. Further, the applet still cannot 
be controlled outsbe of the constraints or environment of the applk:atkxi. In fact, with a second applicatkx> window 
(instance) launched, the first window must become active (in the foreground, under control of cursor or mouse) before 
the applet can be controlled. Further, the traditksnal applet model does not alk>w for iconifk:ation of the applet window 
within the operating environment (minimizing of the window). Under current practice, the application window itself must 

*s be minimized in order to minimize and kxtnify Ihe applet. In that case, the applet rather than having its own icon, will 
the inherit the icon of the browser The lack of window minimization, resizing and other GUI modrficatkan such as 
changing fonts, backgrounds colors, etc., imposes severe constraints on the applet to be independently controlled 
without applk^ation constraints. 

One solutkxi to remove the applcatkxi dependence of executable code modules has been the use of 'plug-ins*. 

so However, unlike 'plug-ins* (file(s) containing data/code used to alter, enhance, or extend the operatkm erf a parent 
application) that are operating environment/platform specific, Java applets are essentially platform independent. Plug- 
ins, which must be downloaded (or come packaged with the application), albw certain file types (such as Shock\Afave™ 
or RealAudb™) whk:h may not be supported Internally by the applfcalwo to be interpreted and output on the kjcal 
platform. However, plug-ins are disadvantageous in that they renr^in resident locally and must be stored on \oca\ disk 

ss for re-use, unlike the virtual machine of Java which is appticatkxi resbent. Importantly, plug-ins spawn processes wholly 
independent of the browser and are thus, platform dependent. Thus, though plug-ins may allow for independent QUI 
control of their windows, they are completely disinherited from the browser unlike Java applets (because they do not 
require a virtual machine to run). Running a plug-in Is akin to running a separate applicatkxi via the operating environ- 
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ment, and thus is not a viable substitute for portable executability as is a Java applet. 

Yet another development (or enhancing capabilities of an application such as a browser is the use of 'helper* 
applications. Helper applications, which are stored locally, do not have the portability and platform independence of 
Java applets, i.e.. a helper application on a Pentium platform cannot be used on a Sun Sparc™ (a product of Sun 

5 Microsystems, the Sun logo and Sparc are trademarks or registered trademarks of Sun Microsystems in the United 
States and other countries) system or vice-versa. The helper application also spawns a new process/thread within the 
operating environment and commands the system resources of a new application instance which is unlike Java applets. 
The helper application is not related to the application delivering the data to be processed and is merely called through 
the operating environment. The helper application does not plug-in or execute within a virtual machine of the application. 

JO Further, a helper application is not easily transferred from host to client, since helper applications can be quite large 
in code size when compared to applets. 

Further, on newer information devices such as network computers (NCs), helper applications and plug-ins may 
not even work due to limited operating environment features and lack of local storage. NCs are conceptually based on 
utilizing remotely stored applets, such as Java applets which are network distributed, to provide applications and content 

'5 to the NC. In contrast, the current industry standard or NCs guarantees that NCs are able to execute Java applets, 
through the use of virtual machine and browser/applicatksn. Even in the NC situation, it is desirable that the applet 
have its own built-in functksnality separate from the browser/application from which it is called. 

Thus, there is a need for a method and apparatus to detach Java applets from the constraints of the appltcatkxi 
so that they can be GUI -controlled directly through the operating environment and so that they not be limited by the 

^ state of the applk:aton in which the applets are spawned. 

SUMMARY 

A method and system is disclosed for detaching Java applets from the constraints of the application which provides 
the Java virtual machine for executing those applets. Thus, the applets, when detached, can appear in a detached 
window whch is more easily controllable by the operating environment desktop. The Java applets continue to run 
under the application's virtual machine but do so with less constraints than the graphical interface limits of the appli- 
cation. Further, if the application that launched the applet transitions to a new URL host, the Java applet continues to 
run. Also, the applet, once detached, can be reattached into the application to appear in an applk:ation history. 

30 

BRIEF DESCniPTION OF THE DRAWINGS 

Figure 1 is a flow diagram of transforming a non-detachable Java applet to have the functionality of detac^iability 
according to an embodiment of the inventton. 
3S Figure 2 illustrates a flow diagram applet behavior when Launched from an application according to an embod- 

iment of the invention. 

Figure 3 is a diagram of exemplary inheritance hierarchy as defined for Java applets. 
Figure 4 is an illustratkxi of a resulting detached applet as rendered on a display screen. 
Figure S shows an applet 'Jukebox* in the attached state. 
<o Figure 6 is a fkDw diagram of the detaching of an applet according to one embodiment of the invention. 

Figure 7 is a flow diagram of the attaching of an applet according to one embodiment of the invention. 

DETAILED DESCRIPTION OF THE INVENTION 

45 Definitions 

The word 'operating environment* refers loan operating system, kernel, shell, or the like which is kDw-level software 
whk:h schedules tasks, allocates storage, handles the interface to peripheral hardware and presents a default interface 
to the user when no application program is mnning. The operating environment also allows application programs to 
50 run by performing storage alkxaton, input/output, etc.. that the applcatbn may request through its executable code. 

The word *desktop* refers to the visual environment (usually output on a display screen) wherein the operating 
environnrrenl allows a user to interact with the operating environment. A desktop includes but is not limited to the display 
and use of icons, cursors, windows, diatog boxes, menus and other user interface elements which are a function of 
the operating environmenL The desktop is a visually rendered screen region wherein application windows and their 
55 associated input/output may be displayed and interacted upon by a user, if desired. 

A 'method* as used in the detailed descripton refers to a functkx) call, procedure or routine associated with one 
or more classes, whch are well-known in the art of object-oriented programming. 

The word 'detachable* refers to the ability of an applet to become free of GUI constraints imposed upon it by the 
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application that spawned the applet. 'Oetachability' implies that the applet Is capable of being manipulated in a graphical 
user interface sense separate of the application that spawned it arKi can instead be manipulated on the desktop by 
interaction directly with the operating environment. 

The word "virtual machine' refers to an interpreter, compiler, linker, etc.. which is included in an application or 
s operating environment to facilitate the execution of instructkxis, pseudo-code and the like for a particular programming 
language such as Java. 

Figure 1 is a flow diagram of transforming a non-detachable Java applet to have the functionality of datachability 
according to an embodiment of the inventkxi. 

Any pre-existing Java applet can be modified to become a detachable Java applet as detachable is described with 

10 respect to var»us embodiments of the invention. When an applet is defined/created, its source code can be modified 
to include methods for detaching the applet. The first step is to add an 'implements Detachable* statement to the class 
definitkxi of the applet (step 110). This implements an interface called 'Detachable'. Appendix A. the Java source code 
for the Jukebox streaming audb applet, shows on column 2, the class definitkxi 'pubic class Jukebox extends Applet 
implements Detachable.' The phrase 'pubic class <Applet Name> extends Applet* is shared by all applets in their 

'5 main class definilbn. The phrase 'implements Detachable* may then be appended to any such definitkxi to begin the 
modification of the <Applet Name> applet to become detachable. Several more steps are desirable in order to complete 
the foundatkyi for detachability of the applet. The Detachable interface invoked via the class definitkxi is implemented 
by adding several generc 'methods* (see Definitkxis. above) to the source code of the applet (step 1 20). The methods 
while generic in terms of the Detachable Interface are peculiar and unk^ue to this embodiment of the invention in that 

^ these methods have not been previously defined in the art of Java devebpment. 

The generic methods will alk>w a Java applet to become detachable from the appitcatkxi in whch they were 
spawned and will alk>w the applet to have the functkxiaiity of any ordinary applicatkxi window running on the operating 
environment (e.g., Solaris^, a product of Sun Microsystems, Solaris is a trademark or registered trademark cA Sun 
Mcrosystems in the U.S. and foreign countries) desktop. TTie generic methods, if they are not adequate for that specific 

2S applet's look-and-feel (checked at step 1 30), may be modified. The generc methods can be rrxxJified to include inter- 
facing that suits the kxik-and-feel or peculiarities of the applet (step 1 40). For example, it may be desired in a detachable 
'chat* (text-based conversatkxi between users) applet that the chat window resize itself to display kxtg strings of text 
which without resizing Itself were invisble. The methods, whch are defined bebw may be modified by one of ordinary 
skill in the art to suit the applet being transformed into a detachable applet. One such modification, described belowt 

30 is the addition of *controller' methods. As described with respect to step 1 20, these generic methods are added to the 
exemplary Jukebox applet code disctosed in Appendix A, 

Generic Detachabte Interface Methods and Modfflcationa Thefeto 

35 1 . 'Detach ' (illustrated as 'public void detach () {' in Appendix A). 

The Detach method is the primary function call alkiwing the applet to be detached from the applcatkxi. The state 
variable 'isDetached* is set equal to true to indicate the applet is now in the detached as opposed to attached state. 
The statement *remove(Ulpanel)* is responsible for removing the 'panel' for the user interface which contains com- 
40 ponents like user interface elements (i.e., buttons, text boxes, menus, icons, etc.). The panel Ulpanel is removed and 
passed onto the 'Detached Frame' class ttiat is instantiated. The 'Detached Frame* class is a platform-independent 
implementatkxt based on the standard Java virtual machine and is thus available to all Java platforms. Code for the 
Detached Frame class is shown in Appendix B. The Detached Frame is instantiated to create a detached window 
(applcatron independent applet vnndow) into whch Ulpanel components (user interface elements) can be rendered. 
• *5 The statement 'controller.mak6Attacfiable(),' is an example of a modification of the generc Detach method that is 
specific to the Jukebox applet that creates a user interface element for attaching the applet back to the applicatkxi. 

2. 'Attach ' (illustrated as 'pubic voki attach () {' in Appendix A) 

so The Attach method is used to re-attach the applet back to the applicatkxi and to ctose the detached window reskiing 

outside of the applicatkxi's window. The state of the applet is returned to attached by setting isDetached equal to false. 
Next, the Detached Frame object is disposed of. The Ulpanel components are then added back to the applcatkxi (add 
(Ulpanel) statement). An example of applet-specific (in this case, the Jukebox applet) modificatkxi to the generc meth- 
od Attach is the controller. makeDetachable statement whch when included provkJes user interface elements for de- 

ss taching out the applet. 
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3. Close (illustrated as "public void ctose()* in Appendix A) 

The Close method kills the Detached Frame window and typically, the applet does not thereafter re-attach to the 
application. This method is useful when total purging oi the applet Is desired. 
5 These generic methods, when added to implement the Detachable interface, will cause a non-detachable applet 

to become detachable (have the lurxtionality of detaching from the application window). 

Figure 2 illustrates a flow diagram of applet behavior when launched from an applicatton according to an embod- 
iment of the invention. 

Though Figure 2 Is directed toward detaching from a application, the methodology ts equally applicable to detach- 

»o ing applets from any environment that executes the applet code through a virtual machine. 

According to step 210, first, the applet must be launched in the virtual machine of the application. This is usually 
accomplished automatically when a user visit a web site (HTML page) which includes statement for launching the 
applet. Assuming that the applet as been transformed according to the methodology of Figure 1, or if the applet is 
already capable of detaching, the virtual machine is checking (waiting) for the user to activate the user element, such 

IS as a button, to detach the applet from the application (checked at step 220). tf the user has activated the 'detach' user 
interface element, then the environment calls the 'Detach' method (step 230). 

The calling of the 'Decach' method, for example, leads to the executon of other instructions as mentoned above. 
One key result of these instructkxis is the displaying of a detached window in whk^ the applet controls and perhaps, 
data would be rendered on to (step 240). Two checks are continuously being performed once the display has rendered 

^ the detached window. The first is to see whether the user changed properties (such as size, background color, etc.) 
of the detached window (step 255). This step is a check performed not from the applicatkxi, but from the operating 
environment itself. If any changes are requested of the properties of the detached window; the operating environment 
initiates and completes those changed properties (step 250). Such changes include resizing the detaching window 
changing the fonts of the window, and since the detached window is a window of the operating environment, minimizing 
and iconificatkxi can be performed without reference, modificatkxi of the application window. Further, the applet in the 
detached window is no kxiger application constrained, and has its own set of graphcat properties-cotor. background, 
font, size, etc.-apart from the applcatbn. The desktop can control the took-and-feel of the detached window, and 
consequently, to some degree, the applet as well. 

The second check being performed is to query if the user activated the user interface element to attach the applet 

30 back to application (step 260). Once the applet is in the Detached Frame, the user interface element (button, etc.) for 
detaching will be replaced by a user interface element for attaching the applet back to the applbatkyi. A request by 
the user to attach the applet to the applk:ation will first cause the 'Attach' method to be called (step 270). The Attach 
method includes several instructions as described above but has the primary functionality of ctosing the detached 
window (step 280) and removing it from the operating environment. The applet is then redrawn into the application 

35 window as when the applet was launched maintaining not the detached look-and-feel, but reverting to the look-and- 
feel of the application which launched the applet. The applet, when redrawn into the application wilt replace the user 
interface element for attach with the user interface element for detach. Thus, the applet can switch states from attache! 
to detached as the user so desires. Not shown in Figure 2 is the case where the applcation has transrtkmed to a new 
host prior to the applet being attached. In that case, the applet, rather than being redrawn in the application window^ 

40 becomes part of the application's 'history'. The history is a record of prevksusly visited URLs so that users of the 
application can return to those URL sites again. 

Figure 3 is a diagram of exemplary inheritance hierarchy as defined for Java applets. 

From object or class inheritance viewpoint, there are two sets of inheritance trees for the vark^us embodiments of 
the inventksn. The first, shown on the right-hand skJe of Figure 3 is the generic Java applet inheritance hierarchy An 
^ Object 310 is inherited into a Component 320. The Component 320 (and consequently Object 310) is inherited into 
Container 330. Container 330 is inherited into Panel 340. Finally, Panel 340 is inherited into Applet 350. 

The second hierarchy shown In Figure 3 is the hierarchy created by inherita/Ke of the Detached Frame. This 
hierarchy is a representation of the melhodok>gy of detaching an applet descnbed with respect to vark>us embodiments 
of the inventkxi. 

so Like the generk: applet inheritance hierarchy, the left side of Figure 3, the Detached Frame inheritance hierarchy 

shows an Object 315 inherited into a Component 325. A Container 335 is, likewise, inherited into a Container 335. 
Rgure 3 shows that the two hierarchies are identical up to and including the Container object. Thus, the hierarchies 
may be joined at Containers 335 and 330. The joining of the inheritance hierarchy is corrceptually the object-oriented 
mechanism allowing an Applet 350 to be transferred from the applicatksn window to the detached frame since both are 
ss instances of class container. One skilled in the art of object-oriented programming will readily be able to utilize the 
property of joined object hierarchies described above to implement the various embodiments of the inventkxi. 
Figure 4 Is an illustratkxi of a resulting detached applet as rendered on a display screen. 
Figure 4 shows a display 400 whk:h may any nrxxiitor, display or other visual devk;e thiat renders a applk:atkxi 
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window 410 through the operating environment. Application witkIow 410 Is shown as an applicatloo window which 
contains several elements such as a picture and URL (Uniform Resource Location) (labeled as 'location*), but may 
be any window or display environment running over the operating environment. Display 400 shows the application 
wirwlow 410 running over an operating environment desktop 430 (see above lor definition of 'desktop'). The operating 

5 environment desktop 430 and applk^tion window 41 0 may be more intimately or tightly integrated such as in Hot Java 
Views ^ (a product of Sun Microsystems, the Sun logo and Hot Java Views are trademarks or registered trademarks 
of Sun Microsystems in the United States andother countries). The invention can be nnodified as to remove any lingering 
visual and user interface constraints of the applicatton window which may restrain an applet however tightly integrated 
the application and environment may seem. In this sense, Figure 4 shows an applet named 'Jukebox' in a detached 

10 window 420. TTie applet was launched at some URL kjcation and initially, contained within applcatkin window 410 (see 
Figure 5). Figure 4 shows the detached state of the applet Jukebox. 

In this detached state, the applet controls 'About', 'Stop' and 'Play' are rendered into the detached window. An 
important aspect to the inventkn is the ability of the applet to continue running or executing its instructions under the 
victual machine (interpreter) of the application wtiose window is rendered in 410. The operating environment and its 

15 desktop 430 now controls the general look-and-feel of the window for the applet Jukebox. The detached window can 
then be rrtanipulated like any other window on the desktop. The applicaton window 410 and the interface properties 
of theapplicatkxi no bnger control, constrain or limit the GUI characteristics of the applet. Further, when the application 
window 410 transitions to a new host URL. the applet continues to run in the Detached Frame. Though the virtual 
machine is platform-dependent, i.e., it must decompose Java code into processor/platform native code, the Java applet 

20 artd its code is not. When the applicatksn closes all of its windows completely, the detached applet is cbsed as it shoukj 
be. Further, the applet, even tfiough detached, must cease execution because it is no longer streaming data from the 
host that was contacted by the applk:atkxi. Thus, the applicatk)n retains control of corK:urrently terminating the applet 
when terminating itself even though the applet is detached from its windowing and interface constraints of the appli- 
cation window. 

25 While in the detached state, several other GUI modifications are available to the detached window which are not 

explcitly illustrated. First, unlike traditnnal applets, a detached window 420 can be iconifted onto an area of the desktop 
430 or minimized into a toolbar or other GUI element without having to iconify the applk:ation window 410 as well. 
TTius, the minimized applet can have its own icon. Further, the detached window 420 may be resized on the desktop 
430 while in the detached state without reference to the height-width tag within the HTML (Hypertext Markup Language) 

30 or other document which specified the calling of the applet from within the application window 410. This alk^ws the 
detached applet greater flexibility in its appearance than the non-detachable applet. Further rrKXfrficatkins such as a 
change of font type, font size, cotor, t^ackgrourxJ, etc.. that are available to other windows njnning on desktop 430 are 
also available for the detached window 420 and the applet it displays. 

TTie detached window 420 contains, in addition to applet control for the Jukebox, a 'control' (a user interface 

35 element) is rendered called 'Attach* which, when activated, will close the detached window 420 and collapse the applet 
back into application wirxjow 410. This 'Attached* state is shown in Figure 5. If application window had transitioned 
to a new host URL, then the applet is included in the application history instead of being instantly executed in the 
application window. 

Figure 5 shows an applet 'Jukebox' in the attached state. 

40 Figure 5 also has a display device 500, an operating environment desktop 530 and a applicatnn window 510. 

When an applet is in the att^hed state, the applicatkxi window 410 constrains it. However, if the applet has been 
made detachable, a 'detach* control (button) is rendered into the application window in the panel of the applet so that 
the attached state may be modified to the detached state leading to a detached window as shown in Rguro 4. Alter- 
natively, the applet can be launched automatically into the detached state with a control for attaching as shown in 

4S Figure 4. A toggle* method can also be provkled to toggle the state of the applet regardless of what the current state 
is. The toggle can be initiated by a user interlace element in both the detached window when the applet is in the 
detached state and the applet panel (in the applk:atlon wirxlow) when the applet is in the attached state. TTie toggle 
method may be desirable where a uniform control is desired in both attached and detached states. The attached state 
shown in Figure 5 is unlike the prkw art since the applet shown is *detachable* via the 'detach control.' An applet 

so without detachability would be limited to the appticatkm itself arKi users woukJ be usable to change the display properties 
of the applet Panel 550 in the applicatkxi wirwiow 510. A detachable applet in the attached state suffers the same 
limitatkxi, but can be freed by activating 'Detach.* The attached applet state of Figure 5 assures that prior to being 
re-attached from a 'detached' state (shown in Figure 4), the host URL of the applcat»n window 510 had not changed. 
Figure 6 is a ftow dragram of the detaching of an applet according to one embodiment of the inventkxi. 

55 The method definition of 'Detach* described above with respect to code Appendix A is not fully represented in 

Rgure 6 but it will be understood by one skilled in the art that any additional steps shown or omitted from the method 
definitkxi can easily be implemented. 

The first step in detaching is to instantiate a new frame called Detached Frame (see Figure 1 description of Detach 
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method) (step 6 1 0). The new frame is then used as a drop-off point for applet data, content and user interface elements/ 
controls. Next, the applet components are removed from the application applet panel (step 620). These components 
are objects including, but not limited to. buttons, controls, user interface elements, action messages, dialog boxes, 
data, etc., which may be renderable to the display device. The applet components are then added to the user interface 
s of the new frame (step 630). Additionally, an 'attach' user interface element is added to the new frame in addition to 
other components so that the applet may ro-attach to the application (step 640). Next, the detached window generated 
through the new frame is mapped or rendered on the dispteiy device (step 645). The detached window is. at this stage 
of the process, a blank window capable of interfacing wHhin the desktop environment of the operating environment. 
As implemented in various embodiments of the invention, the detached window will Inherit size, font, cotor character- 
10 istics of the applet panel as attached in the application window (step 655). Finally, the components, including the attach 
control, are painted on the screen using the Taint All* Java method (step 660). The 'Paint All* method, well-known in 
the art of Java programming, is used to render objects to the display or operating environment, rather than within a 
portkxi of the applrcatbn window. This ensures that connponents for the detached applet will be properly rendered, I. 
e., without showing up as meshed with other screen graphics or as hidden from view. 
'5 Figure 7 is a ftow diagram of the attaching of an applet according to one embodiment of the invention. 

Again, though the flow diagram of Figure 7 may vary from the method *Attach* described earlier, one skilled in 
the an will readily be able to exchange/add features of that method Into the flow diagram of Figure 7 and vice-versa. 

When the attach control is activated, first the new frame instantiated by the calling of the Detach method is disposed 
from the virtual machine environment (step 710). Cksmponents which were removed from the applicatkyi environment 
20 are added back to the application, and automatically rendered in a panel therein as with a typical Java applet (step 
720). Next, the detached window is cbsed (step 730} or removed from the operating environment. Finally, garbage 
collection and reaIk)catlon of menmry (step 740) may be albwed to recycle the resources utilized by the detached 
frame instantiated by the Detach method back to the operating environment 

While the present invention has been particularly described with reference to the various figures, it should be 
25 understood that the figures are for illustration only and shouki not be taken as limiting the scope of the inventon. Many 
changes and modifications may be nnade to the inventkxi, by one having ordinary skill in the art, without departing from 
the spirit and scope of the Invention. 

The processes described above may be performed by a computer program running on a computer in the embod- 
iment described. Such a computer program can be recorded on a recording medium (for example a magnetic disc or 
30 tape, an optk:al disc or an electronic memory device, such as a ROM) in a way well known to those skilled in the art. 
When the recording medium is read by a suitable reading device, such as a magnetc or optical disc drive, a signal ts 
produced which causes a computer to perform the processes described. 

The processes may also be performed by electrons means. 
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Claims 

1 . A process comprising the steps of: 

implementing a detachable intertace; and 

nrxxiifying a non -detachable applet to become a detachable applet. 

2. A process according to claim 1 wherein the step implementing comprises the step of: 

modifying the class definition of said non-detachable applet to include a detachable interface. 

3. A process according to claim 2 wherein the step of modifying comprises the step of: 

adding a set of generic methods for implementing said detachable interface 

4. A process according to claim 3 further comprising the step dl: 

rrxxJifying any of said set of generic methods to suit the desired look-and-feel of said detachable applet. 

5. A process according to step 3 wherein said step of adding comprises the steps of: 

adding a first method for placing said detachable applet into a detached state; and 

adding a second method for placing said detachable applet if in the detached state back to an attached state. 

6. A process according to claim 5 further comprising the step of: 

adding a third method for toggling between said states. 

7. A process according to claim 5 further comprising the step of: 

adding a fourth method for disposing completely said detachable applet while in the detached state. 

8. A process for controlling the behavk>r of an applet exclusive of application constraints comprising the steps of: 

detaching said applet from said application, said applet continuing to utilize a virtual machine of said applicatkxi 
to execute applet instructions; 

displaying a detached window to render visually said applet; and 
enabling the modification of visual properties of said detached window. 

9. A process according to claim 8 wherein the step of detaching comprises the steps of: 

activating a user interface element to detach applet while graphically constrained by said applk^atkxi; and 
calling a Detach method for executing a set of instructions pursuant to completing said steps of detaching, 
displaying and enabling. 

10. A process according to claim 8 further comprising the step of attaching said applet into said application. 

11. A process according to claim 10 wherein the step of attaching comprises the steps of: 

calling an Attach method; 

closing said detached window; and 

redrawing said applet into said application. 

12. A process according to claim 9 wherein the step of calling a detach method initiates the steps of: 

instantiating a new frame; 

removing components of said applet from said application; 
adding said removed components to said new frame; 
mapping said detached window onto a display device; and 

painting said added components onto said display devne, said painting to occur within the mapped detached 
window. 

13. A graphical user interface system for controlling an applet comprising: 
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a desktop defined by an operating environment; 

a application window visuaDy displayed as an overlay on said desktop, said applcatton window displaying and 
visually constraining said applet while said applet is in an attached state; and 

a detached window running directly over said desktop, said detached window being displayed on said desktop 
5 only while said applet is in a detached state, sakj detached state removing sakJ applet from being visually 

constrained and displayed in saki apptk:atkxi window. 

14. A graphical user interface system according to claim 1 3 wherein said detached window includes a user interface 
element tor enabling said applet to be placed in the attached stale. 

w 

15. A graphical user interface system according to claim 14 wherein sad application window ir>cludes a user interface 
element for enabling sakj applet to be placed in the detached state. 

1 6. A graphical user interface according to claim 1 4 wherein sakJ detached window is closed when sakJ applet is placed 
»s In the attached state. 

17. A graphical user interface system according to claim 13 wherein sakJ applet is launched initialty in the attached 
state. 

^ 18. A graphcal user interface system according to claim 13 wherein said applet is launched initially in the detached 
state. 

19. A computer-readable medium having stored thereon applet code tnterpretable by an applicatkxi, sakj applet code 
including sequences of instmctions which, when executed by a processor, cause sakj processor to perform the 

2S steps of: 

detaching said applet from said application, said applet continuing to utilize a virtual machine of said applicatkyi 
to facilitate execution of said sequence of instructkxis by sakl processor; 
displaying a detached window to render visually said detached applet; and 
30 enabling the modification of visual properties of said detached window. 

20. A computer software product having applet code interpretable by an applicatkjn. sakJ computer software product 
distributed to a processor, said applet code including sequences of instructions which, when executed by said 
processor, cause said processor to perform the steps of: 

35 

detaching said applet from said apprtcation, sakJ applet continuing to utilize a virtual machine of said applk:atkxi 
to facilitate execution of said sequence of instructions by sakJ processor; 
displaying a detached window to render visually said detached applet; and 
enabling the modifk»tkxi of visual properties of said detached window. 

40 

21. A signal representative of applet code interpretable by an applcation, said applet code including sequences of 
instructnns whk:h. when executed by a processor, cause sakf processor to perform the steps of: 

detaching said applet from sakJ applk:atkxi, sakJ applet continuing to utilize a virtual machine of said applk:atnn 
to facilitate executkxi of saki sequence of instructions by sakJ processor; 

45 

displaying a detached window to render visually said detached applet; and 
enabling the modifu:atk3n of visual properties of saki detached window. 

22. A method of storing data on a recording medium, the method comprises storing data comprising applet code 
so interpretable by an applk:atk3n, saki applet code including sequences of instmctions vihich. when executed by said 

processor, cause said processor to perform the steps of: 

detaching said applet from said applk:ation, saki applet continuing to utilize a virtual nnachine of saki applcatkxi 
to facilitate executk)n of said sequence of iristructkyis by sad processor. 
ss displaying a detached window to render visually saki detached applet; and 

enabling the modification of visual properties of said detached window. 

23. A signal according to claim 21 , wherein the signal is recorded on a recording medium. 
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24. A signal according to ctaim 23. wherein the recording medium comprises a magnetic disc, a magnetic tape, an 
optica! disc or an electronic memory device. 
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